<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Blurry camera',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2018/04/12.jpg" alt="Purple flowers" class="framed-centred-image" width="649" height="480"/>
<section id="camera">
	<h2>Camera</h2>
	<p>
		I bought a cheap camera today.
		I figured it&apos;d do the usual timestamp-on-photo thing, but hoped it&apos;d be possible to disable that or, even better, switch it into 24-hour time.
		I highly doubted the latter would be possible, but it shouldn&apos;t be too much to ask for the former.
		I found the setting, and as expected, there was no way to configure the timestamp format, but it could be disabled.
		In the test photograph I took though, the timestamp showed up in 24-hour time on its own, which was quite unexpected.
		I imagine many customers are unhappy with this, but it works great for me.
		The date format&apos;s wrong though.
		I debated back and forth over whether to use the timestamp or not, and in the end, I decided to use it.
	</p>
	<p>
		The photos this thing takes are sort of blurry, and given the low resolution of the camera&apos;s screen, you can&apos;t actually see that until you move them to your computer.
		Still, they still have a sort of charm to them, so I&apos;ll keep it.
		That said, I don&apos;t really recommend this camera, so I won&apos;t mention it by name.
		I mean, the photos come out blurry even in low-resolution mode.
		I can only imagine how bad they&apos;d be if I were taking full-sized photographs!
	</p>
	<p>
		Strangely, the thing takes full-sized $a[SD] cards.
		I bought it fully expecting it to use a micro$a[SD].
		I hadn&apos;t seen my full-sized $a[SD] cards or micro$a[SD]-to-full-$a[SD] adaptors in so long, I wasn&apos;t sure I still had them.
		I managed to dig them up though, so everything worked out.
	</p>
</section>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion post for the day:
	</p>
	<blockquote>
		<p>
			One of the major scalability issues in a network is the cost of the hardware.
			Ethernet hardware is relatively inexpensive, leading to a lower cost to employ.
			This low cost though is due to the high demand; producers of such hardware are able to produce in bulk.
			Basically, we have a feedback loop going here: high demand let to low per-unit cost, which leads to further high demand.
			This makes Ethernet more scalable than Asynchronous Transfer Mode in terms of monetary cost, assuming we ignore all other factors.
			However, Ethernet uses preprogrammed $a[MAC] addresses unique to each Ethernet interface to specify which machine a given packet should be sent to.
			In an unswitched network, this is fine, though an unswitched network doesn&apos;t scale well because whenever one machine is sending data, the entire line is tied up and no other machine can use it.
			In other words, unswitched networks don&apos;t scale well, as each machine added to the network has to try to fit in its own communications.
			That said, Ethernet doesn&apos;t scale well with switched networks either.
			Because Ethernet packets specify destinations via the $a[MAC] address and not some sort of address based on location, lookup tables need to be implemented in Ethernet switches, and these tables grow with each machine added to the network (Dordal, 2014).
			Asynchronous Transfer Mode seems to scale even more poorly though, mostly due to the inability to reorder packets, resulting in an inability to effectively send packets along different routes.
		</p>
		<p>
			Interoperability is provided by $a[IP], the Internet Protocol.
			This allows communication between Ethernet networks and Asynchronous Transfer Mode networks, as well as other combinations of same or different network types.
			Because interoperability is provided via the same mechanism for both, there&apos;s nothing to compare or contrast.
			As a side note, $a[IP] is also designed to scale very well, and as it can connect same-type networks, it effectively adds scalability to any type of network, as that network can be broken down into smaller networks and linked together using $a[IP].
			No discussion of how $a[IP] provides this interoperability for Ethernet networks was discussed by the book, though the book did cover how a an $a[IP] connection could be made over an Asynchronous Transfer Mode link, using Asynchronous Transfer Mode Adaption Layers.
			Originally, packets were divided up, padded, and given Asynchronous Transfer Mode headers at the point they reach the Asynchronous Transfer Mode link, then reassembled on the other end and sent onward.
			Extra information was also included in the payload of the Asynchronous Transfer Mode cells to aid in reassembly, further cutting down the amount of throughput.
			Later, a redesign allowed the entirety of the Asynchronous Transfer Mode payload to contain packet data, better utilising the transfer line (Dordal, 2014).
		</p>
		<p>
			When measuring quality of service between these two, we need to define what sort of service we&apos;re after.
			Ethernet uses larger packet sizes than Asynchronous Transfer Mode, resulting in less overhead in the form of headers router-stored sessions.
			For most use cases, this is probably the ideal.
			Ethernet therefore provides better quality of service through faster speeds for most use cases, as it makes more efficient use of the communication line.
			However, Asynchronous Transfer Mode still has advantages in a select few use cases, namely where you don&apos;t have much data to send, but you need it to arrive with very little latency.
			In other words, when you want &quot;real-time&quot; communication.
			The example given by the book was voice communication, but I&apos;m sure other use cases fall into this category as well.
			For such use cases, the smaller packet (known as a &quot;cell&quot;) size allows for the data to be sent quicker, as the full size of the larger packets doesn&apos;t need to be filled with data before the packet can be sent.
			Some waiting for filling is still present, but it&apos;s much less.
			This results in the switches having to store connection information though, as Asynchronous Transfer Mode headers are too small to carry all the data needed for routing.
			Additionally, as packets cannot be interrupted once their transfer begins, the smaller packet size of Asynchronous Transfer Mode allows high-priority traffic to more quickly get in between packets of low-priority traffic, and the high-priority packets need only wait for the finish of a small low-priority packet instead of a full-sized Ethernet packet.
			That said, Asynchronous Transfer Mode isn&apos;t allowed to reorder packets, making it very difficult to send different packets from the same connection along different routes (Dordal, 2014).
			This slows down service in cases where multiple unused paths are available, as one path must handle all the data itself.
		</p>
		<p>
			I didn&apos;t see a discussion of the bandwidth differences between these two in the book.
			It was said that if not for the microheaders and stored connection information, Asynchronous Transfer Mode headers would consume half the available bandwidth themselves due to the packets being roughly half header.
			I can only assume that the bandwidth (data rate) is the same, but the bandwidth (throughput) may differ.
			The smaller packet size seems like it would lead to less throughput, but the microheaders might more than counteract that, leading to more.
			Not enough information was given to answer the question.
			The fixed size of Asynchronous Transfer Mode packets and their headers can be used to calculate how much throughput is lost to headers though, and we see a loss of roughly 9.4%.
			Compare that to the books given 10% loss for Ethernet, and we see a small advantage here for Asynchronous Transfer Mode.
			However, keep in mind that unlike Asynchronous Transfer Mode packets, Ethernet packets are of variable width (Dordal, 2014).
			That means that the 10% is purely an estimation, and it depends on the traffic experienced.
			The two numbers aren&apos;t far apart either, so they very well could be equal much of the time.
		</p>
		<p>
			As for areas that warrant further explanation, I&apos;m curious as to how compatibility between $a[IP] networks and Ethernet networks is provided.
			Are Ethernet packets simply sent over the $a[IP] network mostly unmodified as $a[IP] packets?
			What do you think?
			I&apos;d love to hear other theories.
		</p>
		<div class="APA_references">
			<h3>References:</h3>
			<p>
				Dordal, P. L. (2014, March). 1 An Overview of Networks - An Introduction to Computer Networks, edition 1.9.10. Retrieved from <a href="https://intronetworks.cs.luc.edu/current/html/intro.html"><code>https://intronetworks.cs.luc.edu/current/html/intro.html</code></a>
			</p>
			<p>
				Dordal, P. L. (2014, March). 3 Other LANs - An Introduction to Computer Networks, edition 1.9.10. Retrieved from <a href="https://intronetworks.cs.luc.edu/current/html/otherLANs.html"><code>https://intronetworks.cs.luc.edu/current/html/otherLANs.html</code></a>
			</p>
		</div>
	</blockquote>
</section>
<section id="heat">
	<h2>Heat</h2>
	<p>
		The mould on my windowsill&apos;s gotten pretty bad, the weather&apos;s warmed up, and my gums are healed over, even if not yet healed into the right shape.
		So there&apos;s no gaping holes in my mouth, though there&apos;s still healing left to do.
		Anyway, it all adds up to it being time to shut of the heater again and open up the windows to let out the moisture.
		I really wish I knew how to keep the mould out without leaving the windows open.
		There&apos;s no time today, but I hope to get around to cleaning up the mould soon.
		I&apos;ve even got a face mask this time, so hopefully it won&apos;t make me sick like last time.
	</p>
</section>
END
);
